Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9608/000023_owner-urn-ietf _Mon Aug 19 11:22:23 1996.msg

Internet Message Format | 1997-02-19 | 5KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA29143 for urn-ietf-out; Mon, 19 Aug 1996 11:22:23 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA29136 for <[e-mail]>; Mon, 19 Aug 1996 11:22:21 -0400
Received: from rock.west.ora.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA05394  (mail destined for [e-mail]); Mon, 19 Aug 96 11:22:16 -0400
Received: (from terry@localhost) by rock.west.ora.com (8.6.13/8.6.11) id IAA13231 for [e-mail]; Mon, 19 Aug 1996 08:22:26 -0700
Message-Id: <[e-mail]>
From: Terry Allen <[e-mail]>
Date: Mon, 19 Aug 1996 08:22:26 PDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: [e-mail]
Subject: [URN] re URN rewriting
Sender: [e-mail]
Precedence: bulk
Reply-To: Terry Allen <[e-mail]>
Errors-To: [e-mail]

Lewis wrote:

| There is some suggestion in the framework document that there be a set
| of requirements of new name schemes; any ``enforcement'' is limited to
| that sort of thing.  We have not yet figured out what requirements are
| to be applied, but clearly names will need to be verified somewhere to
| ensure that they are satisying them -- otherwise there might as well
| be no requirements.  So the question becomes, what requirements do we
| want to set?  One possible requirement for NAPTR classic might be that
| the syntax be defined and checked.  What I am suggesting boils down to
| specifying the hierarchy scheme and ensuring that the NAPTR system
| escape names to alternate systems as soon as the hierarchy spec is
| invalidated.

This seems to limit unnecessarily what the NAPTR system can be made to
do, and thus is not an attractive alternative to regexps.

And these requirements:

|   ----------------------------------------
|   Namespace Identifier Requirements and
|   Administration
|   ----------------------------------------
|   Some set of criteria must be established to govern what can and cannot
|   be used as a (top-level) namespace (NID assignment).  This can include:
|     . demonstration of an established namespace management system
|       (including an overview of mechanisms for preventing the
|       duplication/reassignation of name identifiers.  These mechanisms
|       are particular to the individual namespaces).
|     . multi-organization participation in the naming system
|     . rules on how names are assigned, name assignment authority
|       delegation
|     . provision of escape clause

are, I believe, out of scope.  The point is to find ways to resolve those
naming schemes that humanity creates.  It is up to the name space owner
to provide resolution, and not up to the top-level registry to limit how
that resolution may be provided.

Were the top-level registry to decline to include a naming scheme,
people who want to resolve URNs employing that naming scheme would have to find
alternative methods, and "top-level" would cease to be the top level.

| For example, consider the third point; I interpret this as requiring a
| specification of the ways in which collections can be delegated within
| the syntax of the URNs.  The only way I can see to make this work is
| to somehow embed the rules of delegation into the URN syntax so that
| they can be verified syntactically.

Your requirements might be made into a document that recommends ways to
construct naming schemes that are easy to resolve by methods presently
in use or contemplated, but to the extent that your alternative
to regexps is intended to exclude schemes that don't meet these or other
criteria from ever being used, it's not useful.

Two further points:

- it's unwise to overload the syntax of URNs, period.

- delegation and all other matters of URN management policy will be
  decided in the real world (lawyers included), rather than by anyone
  now aware of this discussion.

Ergo, there is no need to, and it is not a good idea to, attempt to
enforce policy within the framework of URN resolution.

I agree with Ron's remark:

| I am opposed to any proposal which allows only the hierarchy set forth
| by the namespace designer. Lots of namespaces will be of the
| form <hierarchical-naming-authority><delimiter><opaque-string>. The
| string is not opaque if the namespace designer can tell the naming
| authorities what to do. I am not opposed to a modification of your
| proposal that essentially says "once you get to the opaque string,
| the rules of hierarchy may change, and naming authorities are free to
| give you a new set of rules by which you can follow the new hierarchy".

which is in accord with what the real world will do.


Regards,

--
       Terry Allen      O'Reilly & Associates, Inc.   [e-mail]
 "In going on with these experiments, how many pretty systems do we build,
  which we soon find ourselves obliged to destroy?"  -  Benjamin Franklin
        A Davenport Group sponsor     http://www.ora.com/davenport/